The purpose of packet switched push-to-talk services is to provide half-duplex voice communication with one or more subscribers eliminating the need for radio transmission while someone else speaks, e.g., as known from walkie-talkie systems.
The basic control mechanism underlying packet switched push-to-talk services, also referred to as floor-control mechanism in the following, guarantees that if a subscriber obtains the permission to talk, e.g., by pressing a dedicated push-to-talk button, then s/he can talk while further subscribers listen until resigning of the active subscriber, e.g., by releasing the push-to-talk button. The push-to-talk service is also designed to simply send and receive voice messages to at least one subscriber selected from an address book of a mobile terminal.
Currently established standards for push-to-talk services only define user-network functions, excluding functions that are based on presence information, and functions necessary to achieve mobile station compatibility at initial deployment of push-to-talk services. Therefore, inter-operability of multiple push-to-talk systems, in particular over wireless communication systems, is left undefined.
FIG. 1 shows a currently established push-to-talk system provided and relying on the Internet protocol IP multimedia subsystem IMS concept, as standardized in 3GPP.
As shown in FIG. 1, for delivery of push-to-talk services there is established a connection between a mobile station 10, an application server 12, and an IP multimedia system 14, via a wireless access network 16, a core network 18, and a service network 20. The mobile station 10 connects to the access network via a base transceiver station 22 being operated under control of the base station controller 24.
As shown in FIG. 1, the inter-working between the access network 16 and the core network 18 is achieved through a serving GPRS support node 26, and the inter-working between the core network 18 and the service network 20 is achieved by the gateway GPRS support node 28. For exchange of data in the different sub-systems, the references Abis, Gb, Gp, Gp, Gn, Gi indicate different interfaces defined, e.g., according to 3GPP, which are commonly known to the skilled person and will therefore not be explained in detail here.
As shown in FIG. 1, the IP multimedia system 14 divides into a call session control function 30 and a media resource function 32.
As shown in FIG. 1, besides the IP multimedia system 14, the application server 12 is provided for group management purposes, e.g., as group list management server GLMS. Also, the communication between the mobile station 10 and the push-to-talk components in the service network uses three push-to-talk over cellular interfaces:                A group management interface Im is used to manipulate access lists and group memberships through a hypertext transfer protocol (HTTP) based on an extension markup language XML protocol, Push-to-talk over Cellular (PoC) Technical Specification, List Management and Do-not-Disturb, PoC Release 1.0, V1.1.3, August 2003.        A signaling interface (Is) is used for session management purposes, Push-to-talk over Cellular (PoC) Technical Specification, Signaling Flows, PoC Release 1.0, V1.1.0, August 2003. The session initiation protocol SIP, IETF RFC 2543 and the session description protocol SDP, IETF RFC 2327 protocols are deployed for session management. These protocols may also be subject protocol compression using SigComp, IETF RFC 3320 and 3321.        The traffic interface It is used for floor control and voice transmission, Push-to-talk over Cellular (PoC) Technical Specification, Transport Protocols, PoC Release 1.0, V1.1.0, August 2003. Heretofore, an audio/video profile/real-time transport protocol AVP/RTP, IETF RFC 3550 conveys speech samples, and the real-time transport control protocol RTCP, IETF RFC 3605 transmits quality reports at the end of push-to-talk bursts. Further, floor-control messages are delivered in application specific extension fields in RTCP headers.        
It should be noted that insofar as reference is made to different protocols, these protocols will be considered as known to the person skilled in the art and will therefore not be explained in more detail but included herein by reference.
Having regard to the push-to-talk architecture shown in FIG. 1, one important issue for operation of such a system is the analysis of provided push-to-talk services. In other words, the potential of push-to-talk services largely depends on its performance because quick access and good speech quality are inevitable pre-requisites for high subscriber penetration.
Therefore, monitoring of push-to-talk performance is especially important during actual operation of the system, where performance problems need to be detected before a larger part of the subscriber population is affected and where the adequate information for trouble-shooting has to be obtained.
As will be outlined in the following, currently only active measurements techniques are available to test performance of push-to-talk services.
One first example is push-to-talk over-the-air, Push-to-Talk Over-the-Air Test System, SPIRENT Communications, 4/04 v.1, http://www.spirentcom.com/documents/1377.pdf, which offers automated active measurement based performance tests for mobile stations and networks. The primary goal of this tool is to perform end-to-end voice quality analysis and service access delay measurements. This test system is connected to two mobile stations that are involved in the quality measurement. Therefore, while it is possible to measure an actual end-to-end performance, this is only achieved between two specific mobile stations.
Further, while active monitoring is quite accurate for a specific push-to-talk session, it is also very cumbersome. In other words, active monitoring and related tests can only be executed from a limited number of dedicated service end points and are therefore difficult to be automated.
Further, a statistical analysis of a large amount of measurement data captured network-wide, e.g., by using many mobile stations involving many base stations, is very expensive and time-consuming and actually infeasible in view of complexity of mobile communication environments installed in the field.
Another option would be to attach a protocol tester to a network interface, e.g., the Gb-, the Gi- or the Gn-interface, and to capture data packets seen at that point in the communication network.
Also, in Kim P. et al., “IMS-based Push-to-Talk over GPRS/UMTS”, Wireless Communications and Networking Conference, 2005, IEEE New Orleans, La., USA, 13-17 Mar. 2005, Piscataway, N.J., USA, IEEE, 13 Mar. 2005, pages 2472-2477, XP010791564, ISBN: 0-7803-8966-2, there is reported the design of a Push-to-Talk operated over a GPRS/UMTS network, so-called Push-to-Talk over Cellular-PoC. There was built a service based on 3GPP IP Multimedia Subsystem IMS to verify the overall PoC approach through an implementation, to discuss design details and to measure results achieved in a live network based on existing GPRS access technology.
Also, in US 2003/0,212,778 A1, there is described an object-oriented modelling approach being used to represent telecommunication services, parameters, and calculation expressions associated with the parameters. Preferably, the Unified Modelling Language UML is used in this regard, and UML sequence diagrams are used to represent the calculation expressions as a sequence of UML methods that accomplishes what is required by the expression.
Nevertheless, the following difficulties arise during analysis of related network interface data, e.g.:                The session initiating protocol SIP messages may be compressed using, e.g., the Sigcomp protocol. Therefore, related messages may contain state information associated with a push-to-talk session, which implies that the contents of individual session initiating protocol SIP messages are impossible to interpret without tracking previous protocol states.        Important end-to-end performance measures cannot be found directly in protocol data fields, except for voice quality in a downlink direction, where jitter and data loss is available. Also, end-to-end performances require searching corresponding events and related data packets on the basis of complex data packet filters.        
Further to the above, there exist performance counters implemented in network nodes which can be used to trace performance problems. However, some of these counters are not dedicated for specific services, but rather for the GSM/GPRS or the UMTS system in general. While there are service related counters in network nodes of post, telephone, telegraph networks, these counters measure only low-level protocol interactions.
Having regard to the application of counters, also here several problems arise as well:                System-specific counters provide rather limited types of statistics, e.g., on the number of data packets or number of subscriber sessions and related packet data protocol contexts arriving in a unit time. Also, system-specific counters can hardly be bound to post, telephone, telegraph services.        Service-specific counters provide basic performance information on aggregate basis, e.g., SIP response time on the basis of a request and a type of a response. Counters do not support detailed performance analysis involving the identification of push-to-talk sessions and corresponding subscribers.        Different vendors implement different counters, log file formats and mechanisms to download from the networking nodes, which makes it ineffective to build an on-line coherent performance monitoring system in a multi-vendor environment. Also, the node resources to this purpose would be limited. In other words, generally significant hardware/software resources would be needed for measuring different performance indicators, increasing the costs of networking elements. Also, a consequence of the resource limitations for counter-based performance analysis schemes is that the time-resolution of these counters is coarse.        
In view of the above, existing solutions do not provide an answer to important questions which arise to network operators:                Were the call-control and the floor-control functions operating fast enough for subscriber satisfaction?        Was the voice quality of successful push-to-talk sessions satisfactory?        Was it possible to identify subscribers, groups of subscribers or network regions in a case where performance problems occurred?        